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SUMMARY 


This  document 
investigation  of  th 
tures  to  geographic 
Department  of  the 
The  purposes  of  thi 
struct  a  geographic 
hierarchical  data  s 
allow  the  evaluat 
geographic  informat 


is  the  final  report  for  Phase  II  of  an 
e  application  of  hierarchical  data  struc- 
al  information  systems,  conducted  under 
Army  Contract  DAAK70-8 1 -C-0059/P00007 . 
s  investigation  were  twofold:  (1)  to  con- 
information  system  based  on  the  quadtree 
tructure,  and  (2)  to  gather  statistics  to 
ion  of  the  usefulness  of  this  approach  to 
ion  system  organization. 


To  accomplish  the  above  objectives,  in  Phase  I  of  the 
project  a  database  was  built  that  contained  three  maps  sup¬ 
plied  under  the  terms  of  the  contract.  These  maps  described 
the  flood  plain,  elevation  contours,  and  landuse  classes  of 
a  region  in  California.  The  map  regions  were  represented  in 
quadtree  form,  and  algorithms  were  developed  for  basic 
operations  on  quadtree-represented  regions  (set-theoretic 
operations,  point-in-region  determination,  region  property 
computation,  and  submap  generation).  The  efficiency  of 
these  algorithms  was  studied  theoretically  and  experimental¬ 
ly. 


On  Phase  II  of  the  project,  the  following  additional 
tasks  were  performed: 

(a)  Query  Language  Design^' high-level  query  language 

permitting  easy  interaction  with  the  database  by  users, 
thus  making  the  quadtree  representation  transparent  to 
the  users. 

(b)  Database  updating;  ^ev^l-epetent  of  algorithms  for  addi¬ 

tion,  deletion,  and  editing  of  data  items  in  a 
quadtree-encoded  database. 

_  ro  v  - 

(c)  Point  and  linear  feature  d  a  t  a  A  -Otrathb-ree*  1  tke  represen- 

tatiOTia^  of  point  and  linear  feature,  data ,  extracted 
from  the  same  geographic  region,  Tiere  also  constructed. 
Algorithms  were  developed  for  interfacing  between  these 
representations  and  the  quadtree-represented  areas. 
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Introduction 


This  project  is  concerned  with  the  applicability  of  a 
class  of  hierarchical  data  structures,  known  as  "quadtrees", 
to  the  representation  of  cartographic  data.  Section  2  de¬ 
tails  the  database  query  language  that  defines  how  the  sys¬ 
tem  appears  to  the  user.  Section  3  presents  the  quadtree  ed¬ 
itor  which  allows  the  user  to  directly  edit  and  update  a 
map.  Section  4  describes  the  quadtree  memory  management 
system  which  allows  the  user  to  manipulate  maps  that  cannot 
fit  in  core.  Section  5  discusses  the  usage  of  the  quadtree 
memory  management  system  to  store  maps  of  point  data  (e.g., 
a  map  of  house  locations)  as  well  as  line  data  (e.g.,  a  map 
of  road  layouts).  Section  6  presents  our  conclusions  and 
future  plana.  At  the  end  of  the  report  is  a  bibliography  on 
quadtrees . 

The  facilities  used  on  the  project  are  described  in  the 
Appendix.  In  particular,  the  display  devlced  used  by  this 
project  la  a  Grinnell  GMR-27  Display  Processor  (see  [Kirb79] 
for  information  pertaining  to  use  of  this  device  at  the 
University  of  Maryland),  referred  to  in  the  rest  of  this  re¬ 
port  as  the  Grinnell. 


2. 2*  An  overview  of  the  query  language 

The  query  language  is  an  English-like  keyword-based  in¬ 
terface  between  the  database  user  and  the  database  system. 
The  query  language  allows  the  user  to  display,  window,  and 
construct  submaps  from  individual  maps,  perform  set- 
theoretic  operations  on  groups  of  maps,  and  extract  various 
kinds  of  information  from  a  map  (e.g.,  find  the  total  area 
of  a  map,  list  the  polygons  in  a  map,  etc.).  It  also  allows 
the  user  to  access  the  quadtree  editor  (described  in  Section 
3)  which  enables  the  user  to  update  maps  and  draw  new  ones. 

The  query  language  is  embedded  in  the  University  of 
Maryland  version  of  FRANZ  LISP  ( [FodeSO] , [ Alle82] ) .  The  en¬ 
tire  database  system  can  be  viewed  operationally  as  a  query 
language  that  is  interpreted  by  LISP  as  LISP  functions  which 
call  C  functions  (i.e.,  functions  coded  in  the  programming 
language  C)  to  actually  process  the  maps.  Thus  all  of  the 
algorithms  of  the  database  are  coded  in  C,  and  LISP  merely 
serves  as  a  convenient  front  end  for  translating  the  query 
language  into  calls  to  C  functions.  Although  normally  it  is 
necessary  to  enclose  a  function  call  in  parentheses  when  us¬ 
ing  LISP,  the  particular  LISP  we  are  using  interprets  an  in¬ 
put  line  containing  three  or  more  words  as  being  implicitly 
enclosed  by  parentheses.  We  make  use  of  this  device  to  give 
the  interface  a  more  natural  appearance  to  users  who  are  not 
used  to  LISP. 

The  query  language  is  keyword  based,  which  means  that 
the  database  ignores  words  that  it  doesn't  understand.  This 
has  the  advantage  that  one  can  Insert  words  and  phrases 
(e.g.,  articles  like  "the"  and  "an")  to  give  the  command  a 
more  natural  appearance,  or  one  can  ignore  unnecessary 
phrases  and  Just  type  the  minimum  to  cause  the  appropriate 
commands  to  be  executed.  This  added  flexibility  is  bought 
at  the  cost  of  more  obscure  error  messages  resulting  from 
the  misspelling  of  a  keyword.  In  order  to  allow  the  user  to 
customize  his  Interface  with  the  database,  there  are  com¬ 
mands  that  allow  keywords  to  be  changed. 

The  syntax  of  the  database  interface  is  explained  in 
Section  2.2.  In  Section  2.3»  an  example  of  an  interactive 
session  with  the  database  is  presented.  Section  2.4  con¬ 
tains  timing  statistics  gathered  when  using  the  database 
system . 
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A  description  of  the  query  language  syntax  is  present¬ 
ed.  Curly  braces  {}  are  used  to  indicate  phrases  in  the 
command  where  a  sequence  of  non-keywords  can  be  inserted - 
These  words  are  used  to  add  clarity  to  the  query.  Some 
standard  sequences  are  shown  in  the  given  command  forms. 

Words  enclosed  in  angle  brackets  <>  are  syntactic  un¬ 
its.  A  syntactic  unit  is  simply  something  which,  when  the 
query  is  typed,  is  replaced  by  its  definition.  For  example, 
suppose  we  had  a  syntactic  unit  <color>  whose  definition  was 
red,  green,  or  blue.  Then  whenever  there  was  a  query  whose 
syntax  contained  the  symbol  <color>  we  would  actually  type 
our  choice  of  red,  green,  or. blue.  The  query  language  is 
presented  by  describing  each  syntactic  unit. 

2.2.J_.  <command> 

The  portion  of  the  query  language  that  corresponds  to 
an  English  sentence  is  a  <command>.  All  other  syntactic  un¬ 
its  correspond  to  words  or  phrases.  The  following  are  the 
allowable  forms  for  a  command: 

Please  {  explain  }  <ayntacbic__unit>  {  } 

Use  {  the  Grinnell  at  }  <window>  {  } 

Measure  {  points  from  the  lower  left  corner  of  }  map  {  } 

Measure  {  points  from  the  }  global  {  origin  } 

Enter  <file_name>  {  into  database  } 

Display  <map>  {  on  Grinnell  } 

Display  <map>  {  on  Grinnell  starting  from  }  <point>  {  } 
Display  {  the  }  value  {  of  }  <number>  {  } 

Let  <name>  {  }  denote  {  }  <object>  {  } 

Let  <name>  {  }  rename  {  }  <map>  {  } 

Describe  {  the  type  of  this  }  <name>  {  } 

Forget  {  about  the  meaning  of  this  }  <key__word>  {  } 

List  {  all  the  }  classes  {  on  }  <map>  {  } 

List  {  all  the  }  polygons  {  on  }  <map>  {  } 

Edit  {  }  <map>  {  with  the  database  editor  } 

Move  {  to  }  <point>  {  } 

Perhaps  most  useful  to  the  beginning  user  is  the  Please 
command.  The  request 

Please  explain  <command> 

gives  a  list  of  the  allowable  forms  for  a  <command>.  In 
general,  one  uses  the  Please  command  as  a  help  function 
which  gives  information  about  syntactic  units. 

The  following  three  commands  are  used  to  initialize  the 
database  system;  the  Use  command,  the  Measure  command,  and 
the  Enter  command.  The  Use  command  enables  the  user  to 
specify  a  portion  of  the  display  device  (in  our  case,  a 
Grinnell  GMR-27)  that  is  to  be  used  in  displaying  the  map. 


The  Measure  commands  tell  the  database  system  how  the  user 
wishes  coordinates  of  points  to  be  Interpreted.  One  can  ei¬ 
ther  measure  locations  from  the  lower  left-hand  corner  of 
the  map  or  from  some  external  global  origin  (defined  when 
the  map  was  built  or  last  edited).  The  Enter  command  places 
the  name  of  a  quadtree  file  Into  the  database's  list  of 
known  quadtree  files.  The  Enter  command  also  checks  the 
file  to  make  sure  that  It  Is  a  quadtree  file. 

There  are  three  different  types  of  Display  commands. 
The  first  type  simply  causes  a  map  to  be  displayed  In  the 
portion  of  the  display  device  that  was  defined  by  the  Use 
command.  This  command  places  the  lower  left-hand  corner  of 
the  map  In  the  lower  left-hand  corner  of  the  display  region. 
The  second  type  of  Display  command  allows  the  user  to  speci¬ 
fy  some  other  part  of  the  map  to  be  placed  In  the  lower 
left-hand  portion  of  the  display  region.  This  Is  particu¬ 
larly  useful  for  displaying  maps  that  are  larger  than  the 
display  region.  The  third  type  of  Display  command  allows 
one  to  display  the  value  of  a  clause  (expression)  without 
first  having  to  bind  the  value  to  a  name. 

There  are  four  commands  that  allow  the  user  to  manipu¬ 
late  the  names  that  the  query  language  Interpreter  knows 
about  (these  are  In  addition  to  the  Enter  command  described 
above):  two  forms  of  the  Let  command,  the  Describe  command, 
and  the  Forget  command.  The  first  form  of  the  Let  command 
enables  the  user  to  associate  a  name  with  an  object.  The 
value  of  the  name  becomes  the  value  of  the  object  at  the 
time  the  Let  was  performed.  The  second  form  of  the  Let  com¬ 
mand  permits  the  user  to  name  a  map  and  at  the  same  time  re¬ 
move  the  old  name  of  the  map*  This  is  particularly  useful 
because  each  map  name  corresponds  to  a  file  In  the  operating 
system  and  one  doesn't  want  to  clutter  up  one's  directories 
with  the  names  of  many  temporary  maps.  The  Describe  command 
tells  the  user  what  the  query  language  interpreter  knows 
about  a  particular  name  (generally  Its  type  and  something 
about  Its  value).  When  the  Describe  command  is  applied  to  a 
quadtree  file,  the  quadtree  file's  header  information  is 
displayed  on  the  terminal.  The  Forget  command  causes  the 
interpreter  to  forget  a  previous  meaning  that  had  been  asso¬ 
ciated  with  a  name. 

Finally  there  are  four  miscellaneous  commands:  two 
types  of  List  commands,  the  Edit  command,  and  the  Move  com¬ 
mand.  The  first  type  of  List  command  allows  the  user  to  get 
a  list  of  the  classes  that  are  used  by  a  particular  map. 
Each  class  corresponds  to  a  color  cn  the  map.  The  second 
type  of  List  command  provides  the  user  with  a  list  of  po¬ 
lygons  (simply-connected  regions)  in  a  map.  Note  that  a  po¬ 
lygon  name  Is  a  class  name  concatenated  with  the  x  and  y 
coordinates  of  some  point  Inside  the  polygon.  The  Edit  com¬ 
mand  allows  the  user  to  access  the  the  quadtree  editor  (QED) 


described  in  Section  3«  The  Move  command  causes  a  cursor  on 
the  display  device  to  be  moved  to  a  specified  location. 


<ayntactic  unit> 

The  possible  <syntact ic_uni t>s  constitute  the  allowable 
parameters  to  the  Please  command.  They  also  correspond  to 
the  actual  syntactic  units  of  the  query  language  grammar 
augmented  by  two  additional  values,  <sy3tem>  and  <syntax>, 
whose  explanations  tell  how  to  interpret  the  results  of  a 
Please  command.  The  following  are  the  allowable 
<syntactic_unit>s : 

<sy3tem> 

<syntax> 

<cla3s> 

<command> 

<cplist> 

<f ile_name> 

<key_word> 

<map> 

<name  > 

<number > 

<ob Ject> 

<point> 

<Polygon> 

<syntactlc_unit> 

< window> 

The  explanation  of  a  <syntactic_unit>  is  an  abbreviated  ver¬ 
sion  of  its  description  in  ^this  document.  Note  that 
<syntactic_unit>3  are  meant  to  be  used  with  angle  brackets 
enclosing  them.  Thus  for  an  abbreviated  version  of  Section 
2.2.1,  one  would  type 

Please  explain  <command> 

An  error  would  result  from  a  request  to  explain  anything 
other  than  one  of  the  <syntactic_unit>3  that  are  listed 
above.  Failure  to  use  angle  brackets  also  ge.erates  an  er¬ 
ror.  Clearly  a  more  forgiving  version  could  be  provided  if 
ever  needed. 

2.2.3,*  <number  > 

A  number  can  be  represented  in  decimal  format  or  by  a 
<name>  that  denotes  a  number.  It  can  also  have  one  of  the 
following  forms: 

{  the  }  area  {  of  }  <map> 

{  the  }  perimeter  {  of  }  <map> 


The  area  form  allows  one  to  calculate  the  total  area  of  the 
non-white  parts  of  a  line,  point,  or  area  map.  The  perime¬ 
ter  form  is  used  to  calculate  the  perimeter  of  the  non-white 


parts  of  an  area  map. 

2.2.J*.  <name> 

A  name  can  be  represented  by  a  letter  followed  by  any 
sequence  of  characters.  Names  are  used  to  denote  keywords 
in  the  query  language  and  the  values  of  objects  created  by 
the  user.  A  name  can  be  used  wherever  the  object  that  the 
name  denotes  can  appear. 

2.2.5.  <polnt> 

A  point  represents  a  location  on  the  map.  A  map  loca¬ 
tion  can  be  specified  in  one  of  the  following  ways: 

{  the  point  where  x  =  }  <number>  {  and  y  =  }  <number> 

{  the  point  at  the  }  cursor 

The  specification  of  a  point  by  the  value  of  its  x  and  y 
coordinates  is  useful  when  these  values  are  known.  Often  it 
is  difficult  to  determine  accurate  x  and  y  values  by  just 
looking  at  the  screen.  When  an  accurate  point  value  is 
needed,  the  most  convenient  way  to  get  it  is  to  position  the 
cursor  at  the  location  on  the  map  that  is  desired.  The  lo¬ 
cation  of  the  cursor  can  then  be  referred  to  using  the  key¬ 
word  "cursor”. 

2.2.6.  <window> 

A  window  describes  a  rectangular  region.  A  window  can 
be  specified  in  one  of  the  following  ways: 

{  from  }  <point>  {  extending  }  <number>  {  by  }  <number> 
{  the  smallest  }  window  {  for  }  <map> 

In  the  first  specification,  <point>  refers  to  the  coordinate 
of  the  lower  left  corner  of  the  window.  It  is  followed  by 
the  width  and  the  height  of  the  window.  The  smallest  window 
for  a  map  is  the  smallest  rectangle  that  encloses  all  the 
non-white  regions  in  the  map. 

2.2.7.  <file  name> 

<file-name>  is  a  special  type  of  name  which  is  inter¬ 
preted  as  the  name  of  a  file  in  the  operating  system.  Only 
such  names  are  valid  parameters  to  the  Enter  command. 

2.2.8.  <map> 

A  map  can  be  denoted  by  a  <file_name>  that  has  been  en¬ 
tered  into  the  database.  It  can  also  be  constructed  by  one 
of  the  following  phrases: 


% 
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{  the  }  intersection  {  of  }  <map>  {  with  }  <map> 

{  the  }  union  {  of  }  <map>  {  with  }  <map> 

{  the  }  windowing  {  of  }  <fflap>  {  with  }  <window> 

{  the  }  map  {  formed  from  }  <cpli3t>  {  in  }  <map> 

{  the  }  points  {  in  }  <number>  {  of  }  <point>  {  in  }  <map> 

The  first  two  phrases  construct  the  obvious  set-theoretic 

results.  There  is  no  phrase  to  construct  the  set-theoretic 
complement  of  a  map,  because  this  can  be  done  easily  in  the 
quadtree  editor  described  in  Section  3.  The  windowing  con¬ 
struction  creates  a  map  whose  lower  left-hand  corner  is  the 
lower  left-hand  corner  of  the  window  and  which  has  had  all 
the  area  that  lies  outside  the  window  painted  white.  A 
<cplist>  is  a  collection  of  classes  and  polygons.  The  map 
formed  from  a  <cplist>  looks  exactly  like  the  original  map 
except  that  all  regions  not  specified  in  the  <cplist>  have 
been  painted  white.  The  <cplist>  construct  in  conjunction 
with  union,  intersection,  and  windowing  will  allow  the  user 
to  create  maps  containing  any  collection  of  polygons  from 
any  set  of  maps  he  desires.  The  points  construction  is  used 
to  build  a  map  of  the  points  within  a  distance  <number>  of  a 
location  <point>  in  a  point  map  <map>. 

2.2.9.  <obJect> 

The  types  of  objects  that  can  be  associated  with  a  name 
are  the  following; 

<class> 

<key_word> 

<map> 

<number > 

<point> 

<polygon> 

<window> 


£.2.J_0.  <cla3S> 

A  class  is  used  to  refer  to  a  collection  of  regions  in 
a  map  that  have  the  same  color.  There  are  two  kinds  of  ob¬ 
jects  that  have  colors  associated  with  them.  One  is  the  po¬ 
lygon,  which  is  a  simply-connected  region  of  one  color,  and 
the  other  is  the  point,  which  is  a  location  that  can  have  a 
color.  Thus  classes  can  be  specified  in  the  following  two 
ways : 


{  the  }  class  {  of  }  <polygon> 

{  the  }  class  {  at  }  <point>  {  on  }  <map> 

The  word  'class'  comes  from  the  concept  of  a  landuse  class  - 
for  example,  all  of  the  wheatfields  might  form  a  class. 
Here  that  notion  has  been  extended  so  that  each  topography 


level  has  a  predefined  class  -  e.g.  all  the  polygons  with 
elevation  below  100  feet  are  part  of  the  class  levell.  Ad¬ 
ditionally  there  is  the  class  of  polygons  which  are  white 
(no  information  or  binary  value  'O').  All  classes  have  a 
unique  color  value,  and  new  classes  can  be  created  on  the 
fly  (and  renamed  if  desired)  by  giving  a  polygon  an  unused 
color . 


2.2.  V1_.  <polygon> 

A  polygon  is  a  simply-connected  region  in  a  particular 
map.  Any  point  in  a  polygon  can  be  used  to  denote  a  po¬ 
lygon.  Thus  the  internal  form  for  a  polygon  is  a  point 
value  concatenated  with  a  map  name.  Sometimes  it  is  useful 
to  have  a  unique  name  for  a  polygon.  A  typical  case  might 
be  when  polygons  of  the  same  class  are  derived  from  two  dif¬ 
ferent  methods,  and  the  user  wishes  to  know  if  they  are  the 
same  polygon.  In  those  situations,  an  arbitrary  ordering  is 
imposed  on  the  points  inside  the  polygon  (corresponding  to 
the  order  in  which  a  tree  traversal  would  find  them)  and  the 
least  point  (according  to  this  ordering)  that  is  inside  the 
polygon  is  used  to  uniquely  denote  the  polygon  (when  con¬ 
catenated  with  the  polygon's  map  name).  Quite  often,  howev¬ 
er,  a  unique  name  is  not  needed.  Since  calculating  unique 
polygon  names  is  expensive,  the  following  two  forms  are 
given  to  allow  the  user  to  specify  a  polygon  and  whether  or 
not  the  name  should  be  unique: 

{  the  }  polygon  {  at  }  <point>  {  on  }  <map> 

{  the  }  unique  {  }  polygon  {  at  }  <point>  {  on  }  <map> 

2.2. JL2.  <key  word> 

The  keywords  recognized  by  the  query  language  are  any 
words  that  appear  outside  the  curly  braces  in  a  syntax 
description.  These  include  the  syntactic  units  (see  Section 
2.4)  and  the  following:  area,  class,  classes,  cursor, 
denote,  global  intersection,  map,  perimeter,  polygon,  po¬ 
lygons,  rename,  union,  unique,  value,  window,  windowing. 
Also  included  are:  Describe,  Display,  Edit,  Enter,  Forget, 
Let,  List,  Measure,  Move,  Please,  Use. 

2.2. J_3.  <cplist> 

A  cplist  is  a  nonempty  list  of  classes  and  polygons. 
This  allows  the  user  to  specify  any  arbitrary  subset  of  po¬ 
lygons  from  an  area  map.  This  is  a  portion  of  the  grammar 
that  could  easily  be  extended  to  Include  various  operators 
for  building  a  list  of  classes  and  polygons  using  set- 
theoretic  operations  in  conjunction  with  the  total  list  of 
classes  or  polygons  in  a  map.  However,  so  far,  no  need  has 
been  found  for  such  a  capability. 
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2.^.  A  demonstration  of  the  query  language 

Below  is  an  example  of  an  interactive  session  between  a 
user  and  the  database.  Our  database  is  a  collection  of  maps 
relating  to  the  Geological  Survey  Map  shown  in  Figure  1 . 
Phase  I  of  our  project  used  three  maps  that  represented 
three  different  partitionings  of  Figure  1 ,  and  are  shown  in 
Figures  2,  3,  and  4.  Note  that  these  figures  represent 
multi-color  maps.  The  first  portion  of  this  demonstration 
will  be  concerned  with  showing  how  the  tasks  of  Phase  I  can 
be  done  using  the  query  language.  We  assume  that  the  data¬ 
base  has  already  been  invoked  via  the  appropriate  system 
calls . 

help 

The  one  word  phrase  help  is  used  to  remind  the  user  of  how 
to  use  the  Please  command.  This  ability  is  not  actually 
part  of  the  formal  query  language,  but  exists  to  maintain 
compatibility  with  the  user's  expectation  that  if  he  types 
help  at  a  system,  he  will  be  told  something  useful. 

Please  explain  this  <system> 

This  is  the  official  way  to  find  out  how  to  get  a  list  of 
the  system  commands. 

Please  explain  <command> 

And  this  is  the  official  way  to  get  the  list  of  the  system 
commands.  These  are  the  same  commands  listed  in  Section 

2.2. 

Enter  flood  into  the  database 
Enter  land  in 

These  two  Enter  commands  verified  that  flood  and  land  are 
names  of  files  that  contain  maps.  A  connection  between 
these  names,  flood  and  land,  and  those  files,  has  been  made 
by  the  query  language  interpreter.  Note  that  flood  is  the 
name  of  the  floodplain  map  and  land  is  the  name  of  the  land- 
use  map. 

Let  be  denote  denote 

This  allows  us  to  use  "be"  anywhere  we  could  use  the  keyword 
"denote".  This  illustrates  how  the  user  can  tiilor  the 
query  language  to  his  own  taste. 

Let  extra  be  land 

Now  both  extra  and  land  can  be  used  as  names  for  the  landuse 
map.  Note  that  this  does  not  create  a  new  map. 
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Describe  extra  please 

The  Describe  command  allows  the  user  to  verify  that  the  pre¬ 
vious  Let  command  actually  worked.  Perhaps  a  more  realistic 
usage  of  the  Describe  command  would  be  to  ask  for  a  descrip¬ 
tion  of  a  name  that  had  been  set  thirty  commands  ago  and 
whose  exact  usage  had  now  been  forgotten. 

Let  X  be  100 
Let  y  be  400 

We  can  now  use  x  and  y  to  denote  100  and  400  respectively. 

Let  2  be  the  polygon  at  x  y  In  extra 

Thus  the  above  command  causes  z  to  refer  to  the  polygon  at 
100  400  In  the  landuse  map. 

Use  0  0  512  512  to  open  Grlnnell 

This  tells  the  database  to  use  a  window  size  of  512  by  512 
(the  entire  Grlnnell  screen)  for  displaying  a  map.  This  Is 
the  standard  size  for  our  maps. 

Let  zmap  rename  the  map  for  z  from  extra 

Now  zmap  la  the  name  of  a  map  that  Is  white  except  for  a  po¬ 
lygon  at  100  400  that  has  been  copied  from  the  landuse  map. 

Let  center  be  map  of  class  at  100  400  In  flood  from  flood 


Now  center  refers  to  a  map  that  contains  only  the  polygons 
of  the  floodplain  map  that  have  the  same  color  as  that  of 
the  polygon  at  100  400  (In  the  floodplain  map). 


Display  center  please 


This  enables 
Seeing  the 
contains  the 


the  user  to  see  the  new  map 
map  we  named  center,  we  note 
left  bank  of  the  floodplain. 


called  center, 
that  It  actually 


Let  left  rename  center 


Thus,  we  rename  It  left. 

Display  center  please 

This  results  In  an  error  message  because  the  rename  form  of 
the  Let  command  does  an  Implicit  Forget  command  on  the  file 
name  that  corresponds  to  Its  object. 


Display  left  please 

Let  frame  be  the  smallest  window  enclosing  zmap 
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Slnce  zmap  is  a  map  containing  only  the  polygon  z,  frame  now 
denotes  the  smallest  rectangle  that  encloses  the  polygon  z. 

Enter  top  into  the  database 

Note  that  top  is  the  name  of  the  topography  map. 

Let  zz  be  the  windowing  of  land  with  frame 

We  have  now  created  a  new  map  that  is  smaller  than  land  and 
includes  that  portion  of  the  landuse  map  that  was  within  the 
smallest  enclosing  rectangle  of  the  polygon  z.  Thus  zz  con¬ 
stitutes  a  map  of  z  with  some  surrounding  context  (as  op¬ 
posed  to  a  map  of  z  surrounded  by  white) . 

Display  zz  quickly! 

Note  that  the  word  "quickly"  has  no  special  meaning  to  the 
system,  although  in  this  ease  the  display  is  indeed  done 
quickly.  A  picture  of  zz  is  shown  in  Figure  5. 

Use  256  256  128  128  to  open  Grlnnell 

Here  we  see  one  of  the  benefits  of  being  able  to  specify 
that  output  is  done  in  a  particular  part  of  the  display  re¬ 
gion.  After  execution  of  the  next  command,  we  will  be  able 
to  have  two  copies  of  the  map  zz  on  the  screen.  Using  this 
type  of  facility,  one  could  edit  a  map  while  simultaneously 
viewing  a  copy  of  the  original  map.  Unfortunately,  the 
current  Implementation  only  allows  manipulation  of  the  map 
in  the  last  window  created  using  the  Use  command.  A  more 
sophisticated  system  might  allow  one  to  edit  more  than  one 
map  at  the  same  time,  much  as  some  text  editors  allow  the 
editing  of  more  than  one  textfile  during  the  same  invoca¬ 
tion. 

Display  zz  please 
Use  0  0  512  512  to  open  Grinnell 

Now  we  resume  using  the  entire  Grinnell  screen. 

Display  the  value  of  the  area  of  left 

Recall  that  left  is  the  name  of  the  left  bank  in  the  flood- 
plain. 

Display  the  value  of  the  perimeter  of  left 

These  Display  commands  are  printing  values  to  the  terminal. 

Let  center  be  a  map  of  class  at  100  300  on  flood  from  flood 

Display  center  please 


This  time  we  make  center  from  the  correct  portion  of  the 
floodplain  (as  shown  in  Figure  6). 


Let  low  be  the  map  of  levell  on  top 
Display  low  please 

Low  is  a  convenient  name  for  a  map  of  the  lowest  contour 
level  in  the  topography  map.  Note  that  levell  is  a  class 
name  that  is  currently  hardwired  into  the  system  and  indi¬ 
cates  the  first  level  in  a  topography  map  (as  shown  in  Fig¬ 
ure  7 ) . 


Let  stepl  be  the  intersection  of  land  with  low 
Display  stepl  please 

Now  we  are  creating  a  new  map  (Figure  8)  that  contains  those 
portions  of  the  landuse  map  that  lie  inside  the  boundaries 
of  levell  in  the  topography  map. 

Let  final  be  the  intersection  of  stepl  with  center 

The  result  of  the  previous  operation  is  in  turn  intersected 
with  the  center  region  of  the  floodplain  map. 

Display  final  please 

Now  the  results  are  on  the  Grinnell  screen  (and  Figure  9) . 

This  particular  result  was  one  of  the  computations  per¬ 
formed  by  the  system  during  Phase  I  and  reported  in 
[RoseSPa].  Recalling  the  sequence  of  operating  system  com¬ 
mands  that  were  necessary  to  perform  the  same  calculation 
before  the  query  language  was  implemented,  one  can  see  the 
merits  of  having  such  a  query  language  associated  with  a  da¬ 
tabase  system.  Such  an  interface  makes  the  commands  more 
easily  understood  and  provides  a  way  of  using  the  system 
that  is  transportable  across  different  operating  systems. 

Phase  II  of  our  project  required  integration  of  line 
and  point  data  into  the  database.  From  the  map  of  Figure  1, 
four  maps  of  line  data  were  extracted.  The  most  interesting 
one  is  shown  in  Figure  10,  and  consists  of  the  roads  shown 
on  Figure  1.  Figures  11,  12,  and  13  show  other  linear 

features  on  Figure  1 .  The  Power  Lines  Map  and  the  Railroad 
Map  are  conceptually  similar  to  the  Road  Map  (although  much 
simpler).  The  City  Border  Map  contains  a  closed  curve  (the 
line  begins  and  ends  on  the  same  point).  This  information 
could  have  been  stored  as  an  area  map  with  the  region  within 
the  city  border  as  a  single  polygon  (a  'black'  area)  and  the 
outside  region  another  polygon  (a  'white'  area).  Converting 
between  line  maps  and  area  maps  in  such  a  way  is  a  task  out¬ 
side  the  scope  of  Phase  II  of  this  project;  however  this 
might  be  a  suitable  task  for  future  work.  Line  maps  are  en- 
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tered  Into  the  database  and  displayed  by  the  same  commands 
as  are  area  maps,  as  is  shown  in  the  following  commands. 

Enter  road  Into  the  database 
Display  road  please 

Line  maps  can  be  Intersected  with  area  maps,  but  not  with 
point  maps  or  other  line  maps. 

Let  lowroad  denote  the  intersection  of  road  and  low 

Display  lowroad 

The  result  of  this  intersection  is  shown  in  Figure  14. 

Display  the  value  of  the  area  of  lowroad 

The  above  returns  the  number  of  pixels  in  the  digitization 
of  the  lines  in  the  map  lowroad.  This  yields  a  rough  esti¬ 
mate  of  the  length  of  the  lines  in  the  map. 

We  also  have  a  set  of  point  data,  shown  in  Figure  15, 
which  corresponds  to  the  location  of  the  houses  on  the  map 
in  Figure  1 .  This  map  can  also  be  entered  and  displayed  in 
a  natural  manner. 

Enter  point  into  database 
Display  point  please 

It  is  possible  to  display  map  expressions,  as  well  as  map 
names,  as  demonstrated  by  the  following  command. 

Display  the  intersection  of  point  with  low 

The  result  of  this  command  is  shown  in  Figure  16.  As  with 
line  maps,  point  maps  can  only  be  intersected  with  area 
maps.  It  is  also  possible  to  ask  for  the  area  of  a  point 
map,  which  has  the  natural  interpretation  of  returning  the 
number  of  points  in  the  map. 
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Figure  2.  The  floodplain  map. 


Figure  3.  The  landuse  map. 


ft  The  map  named 
Figure  8.  ^  map  named 

landuse  map  with  the 


( the 


2.Jt.  Oji  the  timing  of  the  query  language  demonstration 

The  timing  of  the  execution  of  commands  in  the  query 
language,  as  done  for  Phase  II,  is  quite  different  from  the 
timing  of  the  programs  developed  in  Phase  I.  First,  a  dif¬ 
ferent  mechanism  is  performing  the  timings.  In  Phase  I,  a 
system  routine  was  being  accessed  directly  by  the  C  program 
that  was  performing  the  calculation.  In  Phase  II,  the  tim¬ 
ing  is  being  done  by  the  LISP  system.  Therefore,  in  addi¬ 
tion  to  the  time  it  takes  for  the  C  functions  to  perform  the 
query,  our  values  include  the  time  necessary  for  the  LISP 
functions  to  interpret  the  query  language,  parse  the  com¬ 
mand,  and  cross  the  interface  between  LISP  and  C.  Second, 
the  kernel  (which  was  not  used  in  Phase  I)  explicitly  per¬ 
forms  memory  management  functions  that  were  handled  less  ef¬ 
ficiently,  but  invisibly  to  the  Phase  I  timing  mechanism,  by 
the  operating  system  in  Phase  I.  Third,  the  quadtree  file 
representation  used  in  Phase  II  requires  considerably  more 
space  than  the  file  representation  used  in  Phase  I,  but  the 
Phase  I  quadtree  files  had  to  be  read  sequentially,  whereas 
the  Phase  II  quadtree  files  can  be  accessed  randomly.  The 
result  of  this  is  that  in  Phase  II,  commands  that  manipulate 
a  part  of  map  have  been  speeded  up  at  the  expense  of  com¬ 
mands  that  manipulate  the  entire  map. 

The  main  intent  of  timing  measures  is  to  give  a  feel 
for  how  interactive  a  process  is.  Timings  are  most  useful 
when  the  process  being  timed  is  compute  bound  (as  opposed  to 
I/O  bound).  Unfortunately,  it  is  not  clear  whether  signifi¬ 
cant  portions  of  the  database  system  are  compute  bound;  but 
given  this  and  the  above  considerations,  we  submit  the  fol¬ 
lowing  two  timing  results. 

The  first  timing  task  analyzes  a  typical  work  session 
involving  a  wide  variety  of  queries.  Table  1  presents  the 
timings  for  the  query  language  demonstration  of  section  2.3. 
In  both  this  table  and  the  later  table,  time  is  measured  in 
seconds.  Looking  at  the  timings,  we  find  that  the  most  ex¬ 
pensive  operations  are  taking  a  single  area  map  and  con¬ 
structing  a  new  map  that  corresponds  to  a  subset  of  the  re¬ 
gions  in  the  map  or  the  windowing  (clipping)  of  a  region  of 
the  map.  This  is  because  these  operations  require  the  most 
processing  time  per  node  of  the  quadtree.  For  example,  win¬ 
dowing  requires  calculation  of  what  portion  of  each  node 
lies  within  the  window.  The  processing  of  a  node  to  deter¬ 
mine  whether  or  not  it  is  in  a  given  class  (as  is  done  in 
the  case  of  the  construction  of  the  Low  Map)  would  be  trivi¬ 
al  except  that  it  is  done  in  a  general  setting  where  the 
node  could  conceivably  be  compared  to  many  class  or  polygon 
types;  thus  carrying  more  overhead  than  is  obvious  from  the 
usage  given.  The  cost  of  the  intersection  commands  are  not 
surprising  when  one  considers  the  size  of  the  quadtrees  in¬ 
volved  (as  shown  in  Table  2)  in  the  case  of  area  maps  and 
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the  necessary  calculations  performed  per  node  in  the  case  of 
the  point  and  line  map  intersections. 


The  second  timing  task  analyzes  a  single  query  (the  in¬ 
tersection  query)  on  a  wide  variety  of  data.  In  Table  3, 
results  are  shown  for  the  intersection  of  each  of  the  land- 
use  classes  (see  Figure  3  and  the  Phase  I  report  [RoseSPa]) 
with  each  of  the  following  three  maps;  the  Center  map  (Fig¬ 
ure  6),  the  Houses  Map  (Figure  15),  and  the  Road  Map  (Figure 
10).  The  size  information  given  in  Table  3  indicates  the 
result  of  calculating  the  area  of  the  map  that  results  from 
the  intersection.  Note  that  the  time  needed  to  construct  a 
map  for  each  of  the  landuse  classes  is  not  included  in  these 
times.  Recall  from  [Rose82a]  that  the  landuse  class  ws  was 
the  Russian  River  -  Dry  Creek  water  system  of  Figure  1. 
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Table  1 .  Timings  for  Example  Demonstration 
(time  is  measured  in  seconds). 


I  Abbreviated  Command  I  Time  I 


Please  <system>  I  0.1 
Please  <command>  I  0.1 
Enter  flood  I  0.0 
Enter  land  I  0.0 
Let  be  denote  denote  I  0.1 
Let  extra  be  land  I  0.1 
Describe  extra  I  0.0 
Let  X  be  100  I  0.1 
Let  y  be  400  10.1 
Let  z  be  polygon  x  y  extra  I  0.2 
Use  0  0  512  512  I  0.1 
Let  zmap  rename  map  z  extra  I  10.3 
Let  center  be  map  class  100  400  flood  floodi  10.2 
Display  center  I  1.4 
Let  left  rename  center  I  0.1 
Display  center  -  error  return  I  0.0 
Display  left  11.2 
Let  frame  be  smallest  zmap  I  1.0 
Enter  top  I  0.0 
Let  zz  be  windowing  land  frame  I  82.1 
Display  zz  11.0 
Ose  256  256  128  128  1  0.1 
Display  zz  1  2.1 
Use  0  0  512  512  I  0.2 
Display  value  area  left  I  2.1 
Display  value  perimeter  left  I  10.0 
Let  center  be  map  class  100  300  flood  fioodi  13.2 
Display  center  I  1.9 
Let  low  be  map  levell  top  I  34.3 
Display  low  I  1.7 
Let  stepi  be  intersection  land  low  I  67.0 
Display  stepi  I  5.9 
Let  final  be  intersection  stepi  center  1  38.2 
Display  final  '  3.7 
Enter  road  I  0.3 
Display  road  I  3-8 
Let  lowroad  denote  Intersection  road  low  I  30.0 
Display  point  1  1.0 
Display  intersection  point  low  I  5.5 
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Table  2.  Sizes  of  Maps  Referred  to  by  Table  1. 


1 

Name  of  Map 

1  Number  of  Nodes  in  Map 

1 

1 

center 

1 

4687 

1 

1 

extra  (land 

synonym)  I 

28447 

1 

1 

final 

1 

10090 

1 

1 

flood 

1 

5248 

1 

1 

intersection 

point  lowl 

454 

1 

1 

land 

1 

28447 

1 

1 

left 

1 

3197 

1 

1 

low 

I 

4996 

1 

1 

lowroad 

I 

3091 

1 
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Table  3-  Timings  for  Intersection  Task 
Intersection  of  each  class  from  the  landuse  map  with: 

1)  the  center  region  of  the  floodplain  map  (an  area  map) 

2)  the  house  map  (a  point  map) 

3)  the  road  map  (a  line  map) 

(Note:  size  is  measured  in  number  of  non-white  pixels 
time  is  measured  in  seconds) 


1 

1 

Land 

Class 

1  1  Center  Map 

I  1  Time  1  Size 

1  1 

1  I 

Houses  Map 
Time  1  Size 

1  1 

I  I 

Road 
Time  1 
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1 
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The  quadtree  editor  -  a  tool  for  database  update 
2*2*  Ail  overview  of  the  quadtree  editor 

The  quadtree  editor  (QED)  exists  to  facilitate  the  In¬ 
teractive  construction  and  updating  of  maps  stored  as  quad¬ 
trees.  Rather  than  forcing  the  user  to  think  In  terms  of 
the  tree  structure,  QED  tree  manipulation  commands  make  ref¬ 
erences  to  logical  units  of  the  map  (e.g.,  lines,  points  or 
polygons).  The  user  performs  editing  operations  such  as  In¬ 
serting  a  line  or  point,  changing  the  value  of  a  specified 
polygon,  or  splitting  a  specified  polygon  Into  more  than  one 
piece . 

When  many  changes  are  to  bo  made,  the  user  may  wish  to 
see  the  effects  of  each  step.  Commands  are  provided  to  al¬ 
low  him  to  examine  all  or  part  of  the  map  at  a  selected  lo¬ 
cation  on  a  display  device.  This  display  Is  continuously 
updated  as  further  map  manipulation  commands  are  executed. 
Associated  with  each  map's  quadtree  representation  Is  a 
descriptor  termed  the  quadtree  header.  It  contains  Informa¬ 
tion  such  as  the  size  and  location  of  the  map.  There  exist 
commands  which  allow  the  user  to  modify  this  header.  In  ad¬ 
dition,  he  may  also  Insert  textual  comments  Into  the  header 
for  documentation  purposes. 

QED  Is  a  command  based  system  -  l.e.,  the  user  gives  a 
command  and  It  Is  executed,  after  which  the  system  Is  ready 
to  execute  the  next  command.  There  Is  no  notion  of  compos¬ 
ing  functions  as  there  is  in  the  quadtree  database  language. 
When  the  editor  is  ready  to  receive  a  new  command  the  prompt 
<?>  is  displayed.  Area  maps  are  updated  by  use  of  the  re¬ 
place,  change,  and  split  commands  which  replace  all  polygons 
of  a  given  value  with  a  new  value,  change  the  value  of  a 
given  polygon,  or  split  a  polygon  into  multiple  polygons, 
respectively.  Line  and  point  maps  are  updated  by  use  of  the 
insert  and  delete  commands  which  insert  or  delete  lines  or 
points,  respectively.  In  order  that  the  user  may  see  what 
he  is  editing,  there  are  commands  that  draw  all  or  part  of 
the  map  onto  a  selected  section  of  the  Grinnell  display  dev¬ 
ice.  The  user  may  also  alter  the  header  of  the  map. 

To  begin  using  the  editor  from  the  database  system,  the 
user  types 

Edit  <flle>  please 

where  <file>  is  the  name  of  the  disk  file  in  which  the  map 
to  be  edited  is  stored.  If  the  file  does  not  already  exist, 
then  the  editor  assumes  a  new  map  is  to  be  created.  In  this 
case  the  user  will  be  prompted  to  indicate  what  the  map  type 
is  (region,  line,  or  point  data).  New  maps  are  initially 
entirely  white.  If  the  file  does  exist,  then  it  must  be  a 
legal  quadtree  file;  otherwise  QED  informs  the  user  that  the 
file  cannot  be  edited  and  halts.  In  order  to  protect  the 
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user  against  errors  and  machine  crashes,  a  complete  copy  of 
the  file  being  edited  is  made,  and  all  editing  is  actually 
done  on  the  copy.  At  the  termination  of  an  editing  session 
the  old  copy  of  the  file  being  edited  is  stored  in  a  backup 
file,  and  the  copy  containing  the  revisions  replaces  it. 
For  example,  after  editing  a  file  named  "mymap",  the  prior 
version  is  stored  in  the  backup  file  "mymap.bk",  and  the  new 
(edited)  version  will  then  reside  in  "mymap".  The  commands 
typed  while  editing  are  also  recorded  in  a  file  with  the 
suffix  ".ty".  Therefore,  in  this  example,  file  "mymap. ty" 
would  contain  the  commands  used  in  the  last  editing  session. 

Sections  3*2  describes  each  command  in  greater  detail. 
Where  syntax  lines  are  given,  names  enclosed  in  angle  brack¬ 
ets  <>  are  syntactic  type  indicators  -  the  user  would  type  a 
numerical  value  or  name  in  their  place.  Arguments  enclosed 
in  square  brackets  []  are  optional.  In  Section  3*3,  some  of 
the  implementation  details  of  QED  commands  for  region  maps 
will  be  considered.  Implementation  details  for  point  and 
line  maps  may  be  found  in  Section  5.  Section  3 .  *♦  presents  a 
demonstration  of  database  updating  for  an  area  map. 


3.2.  Quadtree  editor  commands 


2.2.J_.  Header  and  comment  commands 

Each  map  file  includes  a  header  which  contains  informa¬ 
tion  such  as  the  width  of  the  map,  its  location  and  orienta¬ 
tion  in  space,  and  the  type  of  data  represented  -  say,  to¬ 
pography  or  landuse  data  for  region  maps,  roads  for  line 
maps.  A  comments  section  is  also  provided  to  allow  the  user 
to  document  his  maps.  The  following  commands  allow  the  user 
to  change  the  header,  add  comments,  and  read  the  header. 
Note  that  once  the  map's  type  has  been  set  to  region,  line, 
or  point,  the  map  type  can  not  be  changed. 

^.£.2. 2.  Header 

Syntax:  Header 

This  command  allows  the  user  to  view  and  alter  informa¬ 
tion  in  the  header.  For  each  item  of  data  contained  in  the 
header,  the  editor  gives  the  user  the  opportunity  to  change 
it.  The  editor  outputs  a  description  of  the  information, 
its  old  value  (in  parentheses)  and  a  prompt  for  the  user  to 
insert  the  new  value.  If  no  change  is  desifed,  typing  the 
return  key  will  leave  that  item  as  is.  The  modifiable 
values  are; 

Map  size  -  All  maps  are  a  square  of  size  N  x  N  where  N 
is  some  integer  power  of  two.  If  the  value  given 
is  not  a  power  of  two,  then  it  will  be  converted 
to  the  least  power  of  two  greater  than  the  given 
value. 

First  X  and  First  Y  -  The  external  coordinates  of  the 
lower  left  corner  of  the  map.  This  might  be  used 
by  other  functions  in  the  database  for  comparing 
the  relative  positions  of  two  maps. 

Rotation  Angle  -  A  real  number  which  is  the  tilt  (in 
radians)  of  the  map  from  the  external  horizontal. 
Once  again,  it  could  be  used  to  compare  two  maps. 

Data  Type  -  A  single  capital  letter.  This  describes 
the  type  of  information  conveyed  by  the  map.  Some 
currently  understood  values  are; 

B  binary  map  (all  polygons  are  black  or 
white) 

T  topography  map 
L  landuse  map 

U  unknown  type 

When  creating  a  new  map,  the  editor  will  automatically 
execute  the  header  command  in  order  to  allow  the  user  to 
give  initial  header  information. 
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^.2.2*2.  Comment 

Syntax:  comment  <comment-llne> 

Add  <comment-line>  to  the  comments  which  are  stored 
along  with  the  header.  These  comments  are  provided  by  the 
user  to  say  whatever  he  wishes  about  the  map.  Some  database 
functions  may  also  add  to  the  comments.  For  example,  when 
QED  creates  a  map,  that  map  receives  a  comment  stating  that 
it  has  been  created  by  QED.  All  comments  are  automatically 
prepended  with  the  date  and  time. 

1*2.1.3.  Print 

Syntax:  print 

Print  out  the  header  and  comments  (see  header  and  com¬ 
ment  commands). 


^.2.2.  Grinnell  manipulation  commands 

The  following  commands  allow  the  user  to  select  the 
section  of  the  map  he  wishes  to  view  and  on  what  portion  of 
the  Grinnell.  When  the  Grinnell  viewing  functions  are  on, 
all  changes  to  the  map  which  occur  within  the  user's  viewing 
window  will  be  displayed. 

3*2.2.^.  Gon 

Syntax;  gon  <fx>  <fy>  <nx>  <ny> 

This  command  selects  (or  changes)  the  section  of  the 
Grinnell  on  which  the  user  will  display  his  map.  The  four 
integers  <fx>,  <fy>,  <nx>  and  <ny>  describe  the  window 
lower  left  x  and  y  coordinates,  width  and  height,  respec¬ 
tively  (the  lower  left  corner  of  the  Grinnell  is  assumed  to 
be  (0,0)).  The  selected  section  of  the  Grinnell  is  erased 
by  this  command. 

3. 2. 2. 2.  Goff 
Syntax;  goff 

This  command  releases  the  Grinnell.  After  this  command 
is  given  the  Grinnell  window  is  erased,  and  no  further 
changes  to  the  map  will  be  shown  on  the  Grinnell. 

3.2.2. ^.  Look 
Syntax;  look  <fx>  <fy> 
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This  command  selects  the  portion  of  the  map  which  is  to 
be  viewed,  and  displays  it  on  the  Grinnell  in  the  window  de¬ 
fined  by  the  last  gon  command.  The  integers  <fx>  and  <fy> 
describe  the  lower  left  x  and  y  coordinates  of  the  portion 
of  the  map  to  be  viewed  (the  height  and  width  are  taken  from 
the  previously  defined  Grinnell  window). 

3. 2. 2. 4.  Point 

Syntax:  Point  <x>  <y> 

This  command  places  a  flashing  cursor  in  the  Grinnell 
window  at  the  point  specified  by  the  arguments. 


Area  map  changing  commands 

The  three  commands  replace,  change  and  split  enable  the 
user  to  make  changes  to  a  region  map.  These  changes  are  re¬ 
flected  on  the  Grinnell  if  they  occur  within  the  current 
user  specified  window  of  the  map  and  a  Grinnell  window  has 
been  opened  by  a  gon  command. 

1*2*1*1*  Replace 

Syntax:  replace  <old-val>  <new-val> 

All  polygons  of  the  map  with  (integer)  value  <old-val> 
will  be  replaced  by  polygons  of  type  <new-val>. 

3*1*1*1*  Change 

Syntax:  change  <x>  <y>  <new-val> 

This  command  changes  the  value  of  one  particular  po¬ 
lygon  of  the  map  to  the  given  (integer)  value  <new-val>. 
The  integer  values  <x>  and  <y>  define  a  coordinate  which 
lies  within  the  polygon  to  be  changed. 

3.2.^.^.  Split 

Syntax:  split  [s]  <val>  [<flle>] 

This  command  is  used  to  split  a  polygon  into  more  than 
one  region.  The  user  supplies  a  chain  code  which  is  drawn 
onto  the  map  with  value  <val>.  Typically,  one  of  the 
resulting  subpieces  of  the  polygon  will  subsequently  be 
given  a  new  value  with  the  change  command. 

The  chaincode  may  be  entered  in  one  of  two  ways.  If 
<file>  is  given,  then  the  editor  gets  the  code  from  a  disk 
file  with  the  name  <file>.  Otherwise,  the  editor  will 


prompt  the  user  to  input  the  chaincode  online.  The  syntax 
of  a  chaincode  is  as  follows: 

(<x>,<y>)<list># 

<x>  and  <y>  specify  the  beginning  coordinate.  Each  direc¬ 
tion  is  either  one  of  the  letters  h,  J,  k  or  1,  or  else  a 
number  followed  by  one  of  those  letters.  The  letters  have 
the  following  meanings: 

h  move  left 

J  move  up 

k  move  down 

1  move  right 

If  a  number  is  given  before  the  letter,  than  the  code  moves 
that  number  of  pixels  in  the  appropriate  direction.  An  ex¬ 
ample  of  a  chaincode  starting  at  (100,100)  and  forming  a  5  X 
5  box  would  be: 

(100, 100)4l4k4h3j# 

As  the  user  types  the  chaincode  (or  as  it  is  read  from 
the  file),  it  is  drawn  onto  the  map.  It  is  also  displayed 
on  the  Grinnell  if  a  window  has  been  opened,  thereby  ena¬ 
bling  the  user  to  see  the  chain  growing  as  he  inputs  it. 

Typing  the  backspace  key  will  erase  the  last  pixel  of  the 

chaincode.  If  the  "s"  option  has  not  been  given  then  the 
chain  may  extend  across  any  number  of  polygons.  If  the  "s" 
option  is  given  then  the  chain  will  stop  when  it  attempts  to 

cross  into  a  polygon  other  than  the  one  it  began  in.  In  ei¬ 

ther  case,  the  chain  will  stop  if  it  attempts  to  go  off  the 
edge  of  the  map. 


3.2.4.  Point  map  changing  commands 

The  commands  insert  and  delete  enable  the  user  to  make 
changes  to  a  point  map.  These  changes  are  reflected  on  the 
Grinnell  they  occur  within  the  current  user  specified 
window  of  the  map  and  a  Grinnell  window  has  been  opened  by  a 
gon  command. 

l.*l*ii*2*  Insgf t 

Syntax:  insert  <x>  <y> 

A  single  point  is  Inserted  at  the  coordinates  specified 
by  <x>  and  <y>.  If  a  point  already  exists  there,  nothing 
will  be  changed. 

3. 2. 4. 2.  Delete 

Syntax:  delete  <x>  <y> 


The  point  at  the  specified  coordinate  is  removed.  If 
no  point  exists  there  the  editor  will  complain,  but  nothing 
will  be  changed. 


3.2.5.  Line  map  changing  commands 


The  commands  insert  and  delete  enable  the  user  to  make 
changes  to  a  line  map.  These  changes  are  reflected  on  the 
Grinnell  if  they  occur  within  the  current  user  specified 
window  of  the  map  and  a  Grinnell  window  has  been  opened  by  a 


gon  command.  While  they  have  the  same  name  as  similar  com¬ 
mands  for  point  maps,  they  take  different  parameters. 

1*2*1*1*  Insert 

Syntax:  insert  <ax>  <ay>  <bx>  <by> 

A  line  segment  is  inserted  from  (<ax>,<ay>)  to 
( <bx> , <by> ) . 

—  Delete 

Syntax:  delete  <ax>  <ay>  <bx>  <by> 

A  line  segment  is  deleted  from  (<ax>,<ay>)  to 
(<bx>,<by>).  If  no  line  segment  exists  over  all  or  part  of 
this  span,  no  change  will  occur  in  che  clear  sections.  If, 
however,  another  line  segment  crosses  the  (non-existent) 
segment  specified  by  the  user,  this  other  line  segment  may 
develop  a  gap  where  the  intersection  occurs.  The  user  is 
encouraged  to  view  line  segments  as  atomic  units  when  delet¬ 
ing.  Only  segments  known  to  have  been  inserte'-'  should  be 
deleted,  and  the  end  points  should  be  given  in  the  same  ord¬ 
er.  The  safest  way  to  delete  a  part  of  a  line  segment  is  to 
remove  the  entire  line  segment  and  then  re-insert  the  ap¬ 
propriate  parts.  This  way  one  avoids  problems  relating  to 
roundoff  errors  in  line  slope  calculations. 

If  used  correctly,  where  the  deleted  line  segment 
passes  through  another  line  segment,  this  other  line  segment 
will  not  be  left  with  a  gap. 


2. 2. 6.  Miscellaneous  commands 
^.2.6.2.  Quit 
Syntax:  quit 


This  command  signals  the  editor  to  save  the  changes 
made  to  the  map  and  finish  processing.  It  Is  the  normal  way 
to  exit  the  editor.  When  this  command  Is  given,  QED  will 
ask  the  user  for  a  parting  comment.  This  makes  it  easy  for 
him  to  keep  a  history  of  editing  sessions  on  the  file.  If 
no  comment  is  desired,  typing  a  carriage  return  will  insert 
no  comment.  Otherwise,  the  user's  comment  and  the  date  will 
be  Inserted  into  the  comments  section. 

Abort 

Syntax!  abort 

This  command  signals  the  editor  to  stop  without  saving 
the  changes  to  the  map.  The  state  of  all  files  is  exactly 
as  it  was  before  the  editing  session  took  place,  except  that 
the  file  which  contains  the  commands  typed  during  an  editing 
session  will  reflect  this  latest  session.  This  command  pro¬ 
tects  the  user  in  ease  of  error. 

3. 2. 6. 3.  Shell 
Syntax!  shell  <command> 

This  command  enables  the  user  to  access  the  UNIX  shell. 
Whatever  the  user  types  as  the  <command>  argument  will  be 
executed  as  though  the  user  were  not  in  the  editor.  After 
the  command  is  executed,  the  bell  on  the  terminal  will  ring, 
and  the  command  prompt  will  be  given. 

3. 2. 6. 4.  Help 


Syntax!  help  [<command>] 

If  <command>  is  not  specified,  then  a  list  of  the  edi¬ 
tor  commands  is  displayed  along  with  their  syntax  (as  given 
on  the  syntax  line  in  this  section)  and  an  extremely  brief 
description  of  their  functions.  It  serves  to  remind  the 
user  of  the  available  commands  and  their  correct  usage.  If 
<eommand>  is  given,  then  a  longer  description  of  that  com¬ 
mand  is  output  on  the  user's  terminal.  The  help  command  (as 
well  as  the  editor  itself)  is  controlled  by  the  map  type. 
This  means  that  the  commands  which  the  user  sees  relate  to 
the  map  currently  being  edited.  If,  for  example,  the  map 
being  edited  is  a  line  map,  help  with  no  <command>  option 
will  give  the  list  of  commands  applicable  to  line  maps.  The 
change,  replace  and  split  commands  will  not  be  listed.  The 
insert  and  delete  commands  will  each  be  listed  with  four 
parameters  for  specifying  line  segments.  Both  asking  for 
help  or  trying  to  execute  a  change  command  while  editing  a 
line  map  will  result  in  the  editor  complaining  that  this 
command  does  not  exist.  Asking  for  help  on  the  insert  com¬ 
mand  while  editing  a  point  map  will  give  the  description  in 


^.2.6.5.  Value 

Syntax:  value  <x>  <y> 

Alternatively;  value  - 

This  command  returns  the  value  or  color  of  the  node  at 
a  given  pair  of  coordinates  in  the  map.  If  is  the  only 

argument,  then  the  coordinates  are  taken  from  the  position 
of  the  Grinnell  cursor.  This  enables  the  user  to  determine 
the  point  visually  via  the  trackball. 

Set 

Syntax:  set  <variable>  <value> 

This  command  allows  the  user  to  change  the  value  of 
certain  user  accessible  variables.  The  only  variable  imple¬ 
mented  in  the  editor  is  called  "global.**  It  may  be  set  to 
either  "true"  or  "false"  and  la  initialized  to  "false."  So, 
to  use  this  command  to  change  "global,"  the  user  would  type: 

set  global  true 

When  global  is  set  to  "false"  all  coordinate  values  supplied 
to  commands  are  interpreted  relative  to  the  lower  left 
corner  of  the  map  being  edited.  When  global  is  set  to 
"true"  all  coordinate  values  are  interpreted  relative  to  the 
global  coordinate  system  -  in  other  words,  the  editor  looks 
at  the  values  for  First  X  and  First  Y  as  set  by  the  header 
command.  These  values  are  subtracted  from  the  given  coordi¬ 
nate  to  calculate  the  position  relative  to  the  lower  left 
corner  of  the  map.  Coordinates  returned  by  editor  commands 
will  also  be  relative  to  the  global  system  when  global  is 
set  to  "true,"  and  relative  to  the  lower  left  corner  of  the 
map  when  global  is  "false." 


As  explained  in  Section  4,  all  quadtree  primitives  and 
memory  management  functions  are  handled  by  an  underlying  set 
of  general  purpose  quadtree  routines.  The  quadtree  editor 
itself  views  these  functions  as  atomic  actions.  The  editor 
proper  is  then  concerned  with  receiving  and  executing  com¬ 
mands  provided  by  the  user. 

When  the  editor  is  called,  the  user  gives  the  name  of 
the  file  to  be  edited.  A  temporary  disk  file  is  created  on 
which  all  editing  is  to  be  done.  Another  file  is  created  to 
store  the  commands  given  by  the  user.  These  files  help  pro¬ 
tect  the  user  from  serious  loss  due  to  system  crashes  or  his 
own  errors  such  as  mistyped  or  unwanted  commands.  They  also 
enable  him  to  abort  the  editing  session  without  damaging  the 
original  copy.  If  the  file  to  be  edited  is  an  old  one,  a 
copy  is  made  in  the  temporary  file.  If  a  new  map  is  to  be 
created,  then  a  default  header  is  Installed  and  the  map  is 
Initialized  as  all  white.  The  memory  management  initializa¬ 
tion  routine  is  executed  and  (for  new  maps)  the  user  is  re¬ 
quested  to  supply  Initial  header  information  through  the 
header  editor  function. 

From  here  on,  the  editor  accepts  commands  from  the 
user.  For  each  command,  it  parses  the  command  line  and  exe¬ 
cutes  the  request.  Many  of  the  commands  were  quite  easy  to 
implement.  The  abort  command  needs  only  to  remove  the 
editor's  temporary  file  (since  the  original  file  and  its 
backup  are  not  affected  by  the  editor) .  The  quit  command 
first  invokes  the  memory  management  functions  which  write 
the  quadtree  and  memory  management  headers  to  disk  along 
with  the  B-tree  pages  currently  in  core,  and  then  moves  the 
original  quadtree  file  to  the  backup  file  and  copies  the 
temporary  (edited)  file  in  place  of  the  original.  The 
header  command  changes  values  in  the  header  structure.  The 
comment  command  passes  the  user's  comment  to  the  memory 
management  function  which  Inserts  the  comment  into  the  com¬ 
ment  list.  Print  uses  memory  management  functions  to  read 
comments  and  then  writes  them  with  the  header  to  the  user's 
terminal.  The  shell  command  uses  a  standard  C  system  call 
to  allow  the  user  to  execute  normal  C  program  calls. 

The  Grinnell  accessing  commands  gon  and  goff  change 
global  variables  used  by  the  map  manipulating  functions. 
These  variables  include  a  Boolean  flag  to  indicate  if  map 
changes  are  to  be  displayed,  and  a  description  of  the  Grin¬ 
nell  window  available.  The  look  command  (after  changing 
other  global  variables  which  describe  the  map  window)  per¬ 
forms  a  traversal  of  the  entire  tree.  For  each  node,  it 
determines  if  the  node  lies  within  the  chosen  map  window.  If 
it  is,  then  the  appropriate  offsets  are  calculated  and  the 
node  is  displayed  on  the  screen. 
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The  commands  value  and  point  were  Included  to  assist 
the  user  in  relating  the  map  coordinates  to  what  is 
displayed  on  the  Grinnell.  Without  them,  choosing  coordi¬ 
nates  for  the  beginning  of  a  chalncode  or  determining  the 
current  value  of  a  polygon  would  be  difficult.  The  value 
command  searches  for  the  node  at  the  requested  location  and 
returns  its  value.  The  point  command  uses  a  standard  Grin¬ 
nell  primitive  function  to  set  the  cursor  to  a  requested  po¬ 
sition. 

In  order  for  the  quadtree  editor  to  be  useful,  a  set  of 
map  manipulating  functions  is  needed  that  permits  the  user 
to  create  any  desired  map.  The  user  of  a  geographic  data¬ 
base  system  such  as  this  will  view  the. units  of  his  map  in 
terms  of  logical  units  such  as  "lines"  or  "polygons,"  and 
not  square  "nodes."  Therefore,  for  region  maps  it  is  clear 
that  the  most  natural  implementation  is  one  that  allows  the 
modifying  commands  to  make  changes  to  specified  polygon.3. 
This  means  that  when  implementing  these  commands  it  must  be 
possible  to  modify  all  of  the  nodes  which  make  up  a  polygon 
or  group  of  polygons  without  affecting  nodes  of  neighboring 
polygons.  In  our  system,  each  node  has  a  value  field.  Each 
polygon  (and  hence  each  node  making  up  the  polygon)  is  con¬ 
sidered  to  be  a  member  of  a  "class".  This  class  could  be  an 
elevation  range  or  a  landuse  type  such  as  "wheatf ields" . 
The  value  of  the  node  indicates  the  class  of  which  it  is  a 
member. 

The  following  commands  apply  only  to  region  maps.  In¬ 
serting  and  deleting  lines  or  points  is  discussed  in  Section 

5. 

The  replace  command  is  executed  by  traversing  the  en¬ 
tire  quadtree.  Those  nodes  with  the  old  (class)  value  have 
that  value  replaced  by  the  new.  For  this  command  it  is  not 
necessary  to  distinguish  between  polygons  of  the  same  class 
since  they  are  all  processed  in  the  same  way. 

The  change  command  is  more  complicated.  This  command 
should  manipulate  only  one  polygon;  however,  other  polygons 
of  that  class  may  also  exist.  After  the  command  line  has 
been  parsed,  a  recursive  function  is  called  which  actually 
performs  the  desired  work.  This  function  takes  a  node  as 
its  parameter.  This  node  is  checked  to  see  that  it  has  the 
old  value  (the  one  to  be  changed).  If  so,  then  its  value  is 
changed  to  the  new  one  and  the  function  is  recursively  ap¬ 
plied  to  all  of  the  node's  neighbors.  In  this  way,  all 
nodes  of  a  polygon  will  eventually  be  reached  and  only  nodes 
in  the  polygon  will  have  their  values  changed  (since  only 
four-neighbors  of  nodes  in  the  desired  polygon  are  ever  can¬ 
didates  for  processing). 
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The  split  command  allows  the  user  to  impose  an  arbi¬ 
trary  line,  one  pixel  wide,  of  a  designated  value  onto  the 
map.  The  Intended  use  of  the  command  is  to  split  a  polygon 
into  two  or  more  separate  parts.  One  of  these  parts  would 
then  become  a  polygon  of  the  same  class  as  the  chaincode  via 
subsequent  invocation  of  the  change  command.  The  pixels  of 
the  chaincode  would  then  be  part  of  this  new  polygon.  Al¬ 
ternatively,  the  split  command  can  be  used  to  make  slight 
modifications  of  only  a  very  few  pixels,  such  as  correcting 
a  slightly  misplaced  border  of  a  polygon.  This  type  of 
correction  could  not  be  applied  in  any  other  way  with  the 
available  command  set. 

The  split  command  operates  by  first  inserting  a  one 
pixel  node  into  the  tree  corresponding  to  the  first  coordi¬ 
nate  given  and  then  following  the  chaincode  inserting  nodes 
as  it  reads  the  code.  As  the  user  types  the  code,  the  code 
is  also  inserted  into  the  command  file.  Allowing  the  user 
to  observe  the  progress  of  the  chaincode  as  he  is  inputting 
it  is  a  key  feature  of  our  implementation  of  the  split  com¬ 
mand.  Typing  an  incorrect  chaincode  was  Judged  to  be  a  very 
common  source  of  error  when  the  implementation  was  designed. 
Enabling  the  user  to  see  the  chain  displayed  as  he  inputs  it 
allows  the  rapid  detection  and  correction  of  errors.  When 
the  backspace  key  is  typed  the  chaincode  is  backed  up  one 
pixel.  This  is  accomplished  by  examining  the  end  of  the 
command  file.  The  last  direction  of  the  code  is  read  to 
determine  the  coordinates  of  the  previous  pixel  of  the 
chaincode  and  then  both  the  map  and  the  command  file  are  up¬ 
dated  to  reflect  the  backup.  In  typical  usage  of  the  split 
command,  the  result  will  be  a  line  splitting  a  polygon  into 
two  or  more  pieces.  The  user  would  then  change  the  value  of 
some  of  the  pieces  via  the  change  command. 

By  repeated  use  of  the  three  commands  replace,  change, 
and  split,  it  is  possible  to  a  make  any  desired  changes  to  a 
region  map.  Clearly  this  is  true  since  in  the  worst  case 
the  user  could  construct  an  entire  map  from  one  pixel  chain- 
codes.  However,  it  is  hoped  that  the  provided  commands  are 
of  sufficient  power  to  enable  a  user  to  easily  edit  maps  as 
he  wishes. 


A  demonstration  of  database  updating . 

Figure  17  shows  the  original  floodplain  data  provided 
for  this  project.  Also  included  are  four  regions  bordered 
by  dotted  lines  indicating  intended  revisions  to  the  landuse 
map.  This  section  demonstrates  how  these  revisions  can  be 
executed  using  the  quadtree  editor.  When  in  the  database 
system,  if  the  user  wishes  to  edit  the  landuse  map  (which 
has  been  given  the  name  'land')  he  would  begin  by  typing: 

Edit  land  please 

The  editor  will  then  start  up,  prompting  the  user  with  the 
symbol  <?>.  Following  are  the  necessary  commands  to  create 
Figure  19  from  Figure  18,  along  with  explanations  of  the 
steps  taken.  Messages  from  the  editor  to  the  user  are  typed 
in  capital  letters. 

OLD  FILE 

<?>  gon  0  0  512  512 
<?>  look  0  0 
DISPLAY  AREA  MAP 
28447  NODES  DISPLAYED 

The  editor  informs  the  user  that  the  file  is  an  old  (already 
existing)  quadtree  file.  The  gon  command  clears  the  Grin- 
nell  screen,  then  the  look  command  displays  the  landuse  map 
for  the  user  to  see.  There  are  28447  nodes  in  this  tree. 

The  map  of  revisions  shows  a  polygon  which  should  have  class 
value  of  ACC.  In  the  original  landuse  map,  this  area  is  two 
polygons  -  the  one  on  the  left  having  value  AVV,  and  the  one 
on  the  right  having  value  ACC.  The  change  command  is  used 
to  convert  the  AVV  part  to  ACC. 

<?>  change  19  247  100 

#  NODES  FOUND:  408,  #  NODES  IN  POLYGON:  112 

This  command  changes  the  color  value  of  the  polygon  contain¬ 
ing  the  point  (19,247)  to  color  100  (the  integer  code  for 
landuse  class  ACC).  During  the  processing,  the  change  func¬ 
tion  examined  408  nodes,  of  which  112  where  actually  in  the 
polygon  and  had  their  value  changed.  The  AVV  polygon  has 
now  merged  with  the  ACC  polygon  to  create  the  desired  revi¬ 
sion  . 

The  AVV  polygon  is  somewhat  harder  to  construct.  On  the 
original  landuse  map,  this  region  contains  a  polygon  of 
class  AVV  and  a  polygon  of  class  ACP.  The  rest  of  the  new 
region  consists  of  two  parts  of  a  large  AVF  class  polygon. 
To  make  the  requested  revision,  it  is  necessary  to  draw  the 
border  of  the  new  polygon  through  the  AVF  section.  This  is 
done  with  the  split  command  in  two  pieces.  The  newly  creat- 
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ed  polygons  will  then  be  converted  to  class  AVV  via  the 
change  command.  Lastly,  the  AGP  polygon  will  be  converted 
to  AVV. 

<?>  split  96 

PLEASE  ENTER  CHAINCODE  (ENDING  WITH  #): 

(32,238)klklklkl1 Ik# 

<?>  split  96 

PLEASE  ENTER  CHAINCODE  (ENDING  WITH  #); 
(62,219)4khkh7k7hJ10h# 

Note  that  96  is  the  integer  code  for  AVV  and  that  the  line 
is  therefore  of  class  value  AVV.  The  following  change  com¬ 
mands  complete  the  AVV  polygon  revision. 

<?>  change  50  211  96 

#  NODES  FOUND:  125,  #  NODES  IN  POLYGON:  33 
<?>  change  29  227  96 

#  NODES  FOUND:  288,  #  NODES  IN  POLYGON:  74 
<?>  change  32  207  96 

#  NODES  FOUND:  265,  #  NODES  IN  POLYGON:  70 

The  UIS  polygon  is  formed  in  a  manner  similar  to  that  used 
to  form  the  AVV  region  -  once  again  the  split  command  is 
used'  to  complete  the  border  of  the  new  polygon,  and  the 
change  command  then  merges  the  pieces  together.  3080  is  the 
integer  code  for  UIS. 

<?>  split  3080 

PLEASE  ENTER  CHAINCODE  (ENDING  WITH  #): 
(53,273)32h10Jljjh4jlJjl21J# 

<?>  change  30  297  3080 

#  NODES  FOUND:  321,  #  NODES  IN  POLYGON:  82 
<?>  change  26  289  3080 

#  NODES  FOUND:  94,  #  NODES  IN  POLYGON:  27 
<?>  change  25  279  3080 

#  NODES  FOUND:  99,  #  NODES  IN  POLYGON:  27 

For  the  final  revision,  the  URS  polygon,  we  simply  draw  the 
complete  border  of  the  polygon  and  fill  in  the  pieces.  3268 
is  the  integer  code  for  URS. 

<?>  split  3268 

PLEASE  ENTER  CHAINCODE  (ENDING  WITH  #): 

(213,205)68l15kl5kllklllkkhkkl10k3h1 5k45hk6h36jh9J 19h6j# 
<?>  change  241  203  3268 

#  NODES  FOUND:  559,  #  NODES  IN  POLYGON:  151 
<?>  change  240  179  3268 

#  NODES  FOUND:  217,  #  NODES  IN  POLYGON:  63 
<?>  change  253  199  3268 

#  NODE  FOUND:  139,  #  NODES  IN  POLYGON:  41 
<?>  change  264  188  3268 

#  NODES  FOUND:  283,  #  NODES  IN  POLYGON:  79 
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<?>  change  260  162  3268 

#  NODES  FOUND:  232,  §  NODES  IN  POLYGON:  63 
<?>  change  276  190  3268 

#  NODES  FOUND:  272,  #  NODES  IN  POLYGON;  77 

The  line  codes  for  this  demonstration  were  of  course 
prepared  beforehand,  and  the  commands  shown  here  are  pol¬ 
ished  final  results.  However,  a  user  who  has  only  a  hard 
copy  map  in  front  of  him  can  determine  by  eye  what  points  to 
use  via  the  point  and  value  functions.  He  can  easily 
correct  errors  while  drawing  line  boundaries  by  using  the 
backspace  key.  So  while  this  demonstration  does  not  show 
commonly  occurring  errors,  these  errors  can  easily  be  dealt 
with  by  the  user  as  he  makes  them. 
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4.  The  quadtree  memory  management  system 

4.J_.  The  user *s  view  of  the  memory  management  system 

The  quadtree  memory  management  system,  henceforth  known 
as  the  kernel,  controls  the  interface  between  the  quadtree 
files  and  the  programs  that  the  database  uses  to  view  and 
manipulate  quadtrees.  At  the  level  of  the  kernel,  the  three 
types  of  quadtrees  (region  quadtrees,  point  quadtrees,  and 
edge  quadtrees)  are  Identical.  The  kernel  views  the  quad¬ 
tree  file  as  a  collection  of  quadtree  leaves,  each  leaf  hav¬ 
ing  some  vslue  associated  with  it.  One  could  view  the  ker¬ 
nel  as  defining  the  quadtree  file  as  an  abstract  type,  as 
all  routines  in  the  database  use  the  kernel  to  acceis  the 
quadtree  files.  The  word  'user'  in  this  section  refers  to 
the  programmer  of  the  quadtree  database  (i.e.  the  'user'  of 
the  kernel  routines),  not  the  'user'  of  the  quadtree  data¬ 
base  system  described  in  Section  2. 

From  the  user's  point  of  view,  a  quadtree  file  has 
three  parts:  an  array  of  user  defined  information,  a  list  of 
comments,  and  a  list  of  quadtree  leaves. 

The  array  of  user  defined  information,  known  as  the 
user's  header,  is  a  fixed  size  array  that  is  set  up  when  the 
quadtree  file  is  created  and  its  usage  is  totally  up  to  the 
user.  The  kernel  supports  the  array  by  offering  the  user  two 
routines:  read_hrad  and  write^head.  These  routines  transfer 
the  user's  header  between  the  quadtree  file  (where  the  user 
can't  change  it,  but  it  is  associated  with  the  file)  and  a 
character  array  (where  the  user  can  change  it,  but  it  is  no 
longer  associated  with  the  file) .  The  routines  read_head 
and  wrlte_head  do  not  allow  access  to  any  part  of  the  quad¬ 
tree  file  that  is  outside  of  the  initially  defined  user's 
header.  Typical  usages  of  the  user's  header  would  be  to 
keep  track  of  whether  a  quadtree  file  is  to  be  Interpreted 
as  a  point  quadtree  or  a  region  quadtree,  the  x  and  y  coor¬ 
dinates  of  the  lower-left-hand  corner  of  the  quadtree  (with 
respect  to  some  global  coordinate  system) ,  and  how  many  pix¬ 
els  wide  the  quadtree  is. 

The  list  of  comments  provides  a  variable  size  disk  area 
where  the  user  can  place  comments  (usually  a  list  of  the 
function  calls  used  in  the  creation  of  the  file).  The  com¬ 
menting  feature  is  maintained  by  three  routines: 
append_cmnt,  read_cmnt,  and  cmnt_init.  Note  that  a  comment 
cannot  be  changed  once  it  has  been  inserted,  because  the 
only  write  capability  is  to  append.  The  read_cmnt  routine 
allows  the  user  to  fetch  the  next  n  characters  of  comments. 
Thus  it  was  necessary  to  provide  a  cmnt_lnit  routine,  to  re¬ 
turn  the  read  routine  to  the  beginning  of  the  comment  list 
(allowing  rereads). 
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Most  of  the  code  in  the  kernel  is  dedicated  to  main¬ 
taining  the  list  of  quadtree  leaves.  The  kernel  user  inter¬ 
faces  with  this  code  through  twenty  C  subroutines  and  mac¬ 
ros.  The  major  distinction  between  these  routines  is  wheth¬ 
er  they  access  the  quadtree  file  or  are  utilities  for  mani¬ 
pulating  quadtree  leaf  descriptions. 

The  quadtree  leaf  description  has  three  parts.  It  con¬ 
tains  the  depth  of  a  leaf  (accessed  via  qd_depth),  the  coor¬ 
dinates  of  the  lower  left  hand  corner  of  the  leaf  (accessed 
via  qd_x  and  qd_y) ,  and  the  user  interpreted  value  of  the 
leaf  (accessed  via  qd_value).  A  leaf  also  lies  in  a  partic¬ 
ular  quadrant  of  its  father;  which  quadrant  the  leaf  lies  in 
can  be  computed  by  qd_whieh.  As  well  as  interpreting  exist¬ 
ing  leaves,  there  are  routines  that  allow  the  construction 
of  leaf  descriptions.  The  basic  constructor  is  qd_clear, 
which  creates  a  leaf  of  depth  0,  with  value  UNUSED,  whose  x 
and  y  coordinates  are  <0,0>  (which  is  always  measured  from  a 
leaf's  lower  left  hand  corner  where  the  entire  tree's  lower 
left  corner  has  <0,0>  for  its  coordinates).  The  user  inter¬ 
preted  value  of  a  leaf  description  can  be  changed  using  the 
qd_set  command.  A  leaf  description  of  a  leaf  having  a  cer¬ 
tain  depth  and  x  and  y  coordinates  relative  to  a  tree  with  a 
given  maximum  depth  is  built  by  the  qd_xy  routine.  A  leaf 
description  for  a  node  which  would  be  The  father  or  son  of  a 
given  node  can  be  built  using  qd_father  or  qd_son  (respec¬ 
tively).  A  copy  of  a  leaf  description  can  be  made  using  the 
qd_copy  routine.  Two  leaf  descriptions  can  be  compared  re¬ 
lative  to  their  visitation  order  by  a  preorder  traversal 
ordering  using  the  addr_gt  function.  The  number  of  bytes 
used  by  a  leaf  description  is  kept  in  a  macro  called 
B__ADDR_SIZE. 

Those  routines  that  access  the  quadtree  file  can  be  di¬ 
vided  into  those  that  search  the  file  and  those  that  change 
the  file.  The  most  basic  of  the  functions  that  search  the 
file  is  qd_find.  Given  a  leaf  description,  it  returns  the 
description  of  the  leaf  in  the  quadtree  that  would  contain 
the  given  leaf.  Sometimes  the  leaf  to  be  found  is  larger 
than  the  actual  leaves  at  the  appropriate  position  in  the 
file,  there  is  no  'containing'  leaf.  In  this  case,  qd_find 
returns  the  leaf  in  the  quadtree  contained  by  the  given 
leaf's  description  that  is  least  (using  the  ordering  defined 
by  addr_gt).  If  one  wants  to  find  a  leaf  description  in  the 
quadtree  that  is  the  preorder  successor,  neighbor  with 
respect  to  a  particular  aide,  or  a  diagonal  neighbor,  then 
one  uses  the  qd_preorder,  qd_neighbor,  or  qd_diagonal  func¬ 
tions  (respectively).  Often  one  wishes  to  apply  the  same 
function  to  every  leaf  in  a  quadtree.  One  way  to  implement 
this  would  be  to  have  the  function  be  the  body  of  a  loop 
that  calls  qd_preorder  until  it  runs  off  the  end  of  the  map. 
However,  qd_preorder  works  by  first  calculating  the  value  of 
the  successor  of  a  given  leaf,  and  then  searching  for  this 


newly  oalculated  leaf.  Since  we  know  that  we  wish  to  exe¬ 
cute  the  same  function  on  every  leaf  in  the  tree  in  any  con¬ 
venient  order,  it  is  not  necessary  to  search  for  a  particu¬ 
lar  leaf.  Instead  we  can  use  whatever  leaf  is  next  in  the 
tree.  Qd_travel  is  a  kernel  routine  which  takes  a  function 
as  its  argument,  and  applies  this  function  to  every  leaf  in 
the  file  in  the  moat  efficient  manner. 


The  principal  way  to  change  a  quadtree  file  i 
aert  a  leaf  using  the  qd_insert  routine.  If  one 
leaf  description  that  is  identical  to  one  that  is 
the  quadtree  (except  for  the  leaf  having  a  differe 
then  the  color  associated  with  that  leaf  descr 
changed  and  if  that  causes  any  leaves  to  merge  (d 
siblings  having  the  same  color),  then  those  1 
merged.  If  the  leaf  description  to  be  inserted  d 
leaf  that  contains  more  than  one  leaf  already  in 
tree,  then  the  contained  leaves  are  deleted  and  th 
is  inserted.  Thus  one  can  empty  a  quadtree  by  in 
white  leaf  at  depth  zero.  If  one  Inserts  a  leaf  d 
that  is  contained  by  a  leaf  description  that  is  a 
the  quadtree,  then  the  leaf  in  the  quadtree  is 
its  four  sons  (each  with  the  same  color  as  the  fa 
the  insertion  attempt  is  repeated.  There  is  also 
file  changer  called  qd_packer  that  tries  to  compre 
rangement  of  leaves  in  the  quadtree  file, 
qd^packer  can  change  the  quadtree  file,  its  effect 
visible  to  the  routines  described  above' (with  the 
that  most  routines  run  faster  on  a  quadtree  file 
been  packed ) . 
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re  two  routines  needed  to  monitor  the 
external  operating  system,  in  which  the 
t  across  many  invocations  of  the  data- 
kernel,  whose  memory  vanishes  when  the 
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The  major  question  in  the  implementation  of  the  kernel 
is  to  decide  how  to  order  the  storage  of  the  leaf  descrip¬ 
tions.  It  can  be  seen  [Garg82a]  that  if  one  orders  the 
leaves  according  to  how  they  would  be  visited  by  a  preorder 
traversal  of  the  quadtree,  then  the  next  leaf  description 
sought  will  tend  to  be  near  the  last  leaf  description  found. 
In  the  kernel,  a  leaf  description  is  stored  in  two  long 
words  (32  bits  each).  The  first  long  word  is  split  into  one 
field  of  3  bytes  (24  bits)  that  contains  the  result  of  in¬ 
terleaving  the  bits  of  the  x  and  the  y  coordinates  of  the 
leaf  described.  The  second  field  of  1  byte  (8  bits)  con¬ 
tains  the  depth  of  the  leaf  described.  It  can  be  shown  that 
if  one  compares  this  four  byte  address  descriptor  of  two 
leaves  (using  an  arithmetic  comparison  of  the  absolute  value 
of  the  two  long  words),  then  the  leaf  corresponding  to  the 
greater  value  will  be  visited  later  by  a  preorder  traversal 
of  a  quadtree  than  will  the  other  leaf.  Thus  we  have  a 
quick  and  efficient  way  of  determining  a  linear  ordering  of 
leaf  descriptions.  The  second  long  word  of  the  leaf 
description  is  used  to  store  the  value/color  of  the  leaf. 
Mote  that  this  leaf  description  structure  will  support  quad¬ 
trees  with  leaves  at  depth  twelve  or  less.  This  limit  ar¬ 
ises  from  the  3  bytes  (24  bits)  that  are  used  to  store  the 
interleaved  coordinates.  This  gives  a  maximum  size  of  2048 
by  2048  pixels  for  any  map.  Our  original  database  consists 
of  three  maps  each  approximately  400  by  450  pixels,  so  this 
is  quite  sufficient. 

Given  the  linear  ordering  of  leaf  descriptions 
described  above  and  the  fact  that  we  will  be  storing  collec¬ 
tions  of  leaf  descriptions  containing  as  many  as  30,000 
leaves,  it  is  obvious  that  the  quadtree  files  should  be  or¬ 
ganized  as  some  kind  of  b-tree  structure  [Come79].  The  ker¬ 
nel  thus  becomes  a  collection  of  routines  that  maintain  a 
buffer  pool  in  core  and  a  b-tree  in  the  disk  file,  allowing 
the  user  to  manipulate  the  leaf  descriptions  without  having 
to  worry  about  any  of  the  details.  Note  that  the  buffer 
pool  contains  that  portion  of  the  quadtree  file  that  there 
is  room  for  in  core  at  any  given  time  and,  due  to  locality 
of  reference  considerations,  is  probably  beat  maintained  on 
a  schedule  that  replaces  the  least  recently  used  buffers 
first . 

We  are  currently  using  512  byte  b-tree  nodes,  which  al¬ 
low  room  for  up  to  sixty  leaf  descriptions.  Each  b-tree 
node  (except  the  root  of  the  b-tree)  is  guaranteed  to  have 
at  least  thirty  leaf  descriptions  in  it.  Thus  one  will 
rarely  build  a  b-tree  that  is  deeper  than  four  b-tree  nodes. 
There  is  much  research  that  can  be  done  with  regards  to  the 
kernel  implementation.  It  would  be  interesting  to  know  the 
effects  of  different  size  b-tree  nodes,  different  size 
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buffer  pools,  and  different  b-tree  node  balancing  schemes  on 
the  response  time  of  the  kernel. 


5.  Point  and  line  data 

In  the  final  report  on  Phase  I  [RoseSPa],  the  details 
of  implementing  region  quadtrees  were  discussed.  In  Phase 
II,  quadtrees  were  also  used  to  store  two  new  types  of  data: 
points  and  lines.  The  details  of  our  usage  of  quadtrees  for 
these  two  new  data  types  will  be  discussed  below.  It  should 
be  noted  that  the  same  kernel  (described  in  Section  4)  is 
used  for  manipulating  quadtrees  involving  each  of  these 
three  data  types.  When  storing  area  data  in  region  quad¬ 
trees,  the  value  of  a  leaf  corresponds  to  the  color  of  the 
region  that  contains  the  leaf.  Since  there  is  no  notion  of 
color  associated  with  either  point  or  line  data,  other  in¬ 
terpretations  will  be  placed  on  the  information  stored  in 
the  value  portion  of  the  leaf  description.  What  interpreta¬ 
tion  a  particular  routine  makes  of  a  leaf's  value  is  depen¬ 
dent  on  what  type  of  d^ca  is  being  stored  in  the  quadtree. 
The  user  keeps  track  of  this  in  the  user  header  described  in 
Sections  4.1  and  3.2.1. 

To  be  precise,  the  routines  that  manipulate  region 
quadtrees  view  the  32  bit  value  field  associated  with  each 
leaf's  location  as  containing  three  subfields.  The  first 
field  (leftmost  bit)  is  set  to  indicate  that  an  erroneous 
value  has  been  placed  there.  This  corresponds  to  using  a 
negative  long  integer  as  the  value  of  a  node.  As  it  hap¬ 
pens,  the  routine  that  creates  an  empty  leaf  description 
(qd__clear)  places  a  -5  in  the  value  field  to  indicate  that 
no  one  has  specified  a  value  for  this  leaf  description  yet. 
This  is  consistent  with  the  usage  described,  as  something  is 
probably  wrong  if  there  la  a  leaf  description  in  the  tree 
that  does  not  have  an  assigned  value.  The  second  field 
(also  a  one  bit  field)  is  the  mark  bit  that  is  used  by 
sweep-and-mark  type  algorithms,  e.g.,  connected  component 
labeling.  The  remaining  field  (30  bits)  contains  the  color 
of  the  described  leaf. 

The  implementation  of  the  point  quadtree  interprets  the 
value  field  as  containing  five  subfields.  The  first  two 
fields  are  the  error  and  mark  fields  that  are  used  just  as 
in  the  region  quadtree.  The  third  field  (two  bits)  is 
unused.  The  fourth  field  (14  bits)  contains  the  x- 
coordinate  of  the  point  stored  in  the  leaf.  The  fifth  field 
(also  14  bits)  contains  the  y-coordlnate  of  the  same  point. 
Fourteen  bits  is  more  than  sufficient  considering  the  imple¬ 
mentation  restriction  of  using  quadtrees  with  a  depth  leas 
than  or  equal  to  twelve.  Note  that  a  depth  of  twelve  will 
handle  a  2048  by  2048  map.  Thus  we  can  interpret  a  y  value 
of  4096  as  an  unused  value  that  can  be  used  to  denote  a  leaf 
description  for  a  region  that  contains  no  points. 
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The  above  Interpretation  of  the  leaf  description  value 
field  has  the  following  consequences  with  respect  to  point 
quadtree  algorithms.  No  more  than  one  point  can  be  stored 
in  a  quadtree  leaf.  Insertion  of  a  point  in  a  point  quad¬ 
tree  works  as  follows.  First  we  find  the  leaf  that  contains 
the  point's  location.  If  the  leaf  is  empty,  then  the 
point's  X  and  y  coordinates  are  placed  in  the  leaf  descrip¬ 
tion.  Otherwise,  the  leaf  is  split  into  its  four  sons,  the 
old  leaf's  point  value  is  copied  into  the  appropriate  son, 
and  insertion  is  re-attempted.  Deletion  of  a  point  in  a 
point  quadtree  is  a  matter  of  finding  the  leaf  that  contains 
the  point  and  then  changing  the  leaf  description  to  that  of 
an  empty  leaf.  Next,  one  checks  to  see  if  it  is  possible  to 
merge  the  new  empty  leaf  with  its  siblings. 

The  point  quadtree  described  above  differs  from  the 
original  point  quadtree  of  Finkel  and  Bentley  CFink74],  in 
that  the  structure  of  our  point  quadtree  is  independent  of 
the  order  of  point  insertion.  This  is  a  result  of  the  fact 
that  leaves  are  always  split  by  the  kernel  into  four 
congruent  squares,  whereas  the  original  point  quadtree  split 
leaves  up  into  rectangles  whose  dimensions  were  a  function 
of  the  first  node  Inserted  into  the  leaf's  region. 

The  value  field  of  the  line  quadtree  leaf  description 
has  four  subfields.  The  first  field  (one  bit)  indicates  er¬ 
ror  values  as  it  does  for  the  other  two  types  of  quadtree 
leaf  descriptions.  The  second  field  (one  bit)  indicates 
whether  or  not  the  leaf  corresponds  to  a  single  pixel  in  the 
map.  The  third  field  (two  bits)  tells  which  son  a  node  is 
with  respect  to  its  father.  By  setting  this  field,  we 
guarantee  that  the  leaf  will  not  be  automatically  merged 
with  its  brothers  by  the  kernel's  insert  routine.  The  only 
time  this  field  is  not  set  is  when  the  leaf  contains  no  line 
segments.  Thus  empty  regions  automatically  merge. 

The  fourth  field  (28  bits)  of  the  line  quadtree  in¬ 
terpretation  of  a  leaf's  value  contains  different  informa¬ 
tion  depending  on  whether  or  not  the  leaf  corresponds  to  a 
single  pixel  in  the  map.  If  the  leaf  corresponds  to  a  pix¬ 
el,  then  the  fourth  field  Indicates  how  many  lines  pass 
through  that  pixel.  If  a  leaf  corresponds  to  a  larger  re¬ 
gion,  then  it  is  either  empty  (and  contains  a  special  empty 
leaf  code)  or  it  contains  exactly  one  line  segment.  If  it 
contains  exactly  one  line  segment,  then  the  intercepts  of 
the  line  segment  with  the  leaf's  region  are  stored.  Since 
the  line  must  Intercept  the  region  at  the  region's  perime¬ 
ter,  it  is  possible  to  encode  each  Intercept  with  14  bits 
and  be  able  to  handle  regions  as  large  as  4095  by  4095.  In 
our  implementation,  this  fourth  field  is  further  split  into 
four  subfields.  The  first  two  bits  determine  the  side  of 
the  node  on  which  the  first  intercept  occurs.  The  next  12 
bits  indicate  how  far  from  the  corner  the  intercept  occurs 


(the  left  corner  for  the  north  and  south  edges,  the  lower 
corner  for  the  east  and  west  edges).  The  next  fields  of  two 
and  12  bits  repeat  this  for  the  second  intercept. 

The  insertion  and  deletion  algorithms  for  line  quad¬ 
trees  are  designed  so  that  if  one  viewed  the  line  segment  as 
an  indivisible  atomic  unit,  then  line  segments  could  be 
dynamically  inserted  and  deleted  without  roundoff  errors 
creeping  into  the  map  representation  to  the  extent  that  a 
line's  endpoints  have  changed.  This  is  important  because 
the  only  way  of  indicating  a  line  is  by  specifying  its  end¬ 
points.  Note  however  that  the  representation  does  not  ex¬ 
plicitly  store  the  endpoints  of  a  line  segment,  but  rather 
stores  a  compact  form  of  the  digitization  of  all  the  lines 
in.  the  map.  The  digitization  of  the  lines  is  eight- 
connected,  l.e.,  connection  of  the  line  is  maintained 
across  horizontal,  vertical,  or  diagonal  neighbors. 

With  the  above  details  in  mind,  the  insertion  and  dele¬ 
tion  algorithms  for  line  quadtrees  are  analogous  to  those  of 
region  or  point  quadtrees.  Insertion  of  a  second  line  seg¬ 
ment  into  a  region  described  by  a  leaf  already  containing 
one  line  segment  causes  the  leaf  to  be  quartered,  the  infor¬ 
mation  that  was  in  the  original  leaf  to  be  distributed  among 
the  new  leaves,  and  then  the  insertion  attempt  is  repeated. 
The  Important  thing  to  remember  is  that  when  a  line  segment 
lies  across  two  leaves,  the  appropriate  intercepts  in  both 
leaves  must  be  eight-neighbors  of  each  other.  Deletion  of 
line  segments  is  simply  a  matter  of  deleting  all  the  infor¬ 
mation  that  is  specific  to  that  line  segment. 
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6.  Conclusions  and  plans 
6.1.  Conclusions 


This  project  has  developed  a  set  of  software  tools  for 
use  with  a  quadtree-encoded  cartographic  database.  A  query 
language  was  developed  to  make  it  easier  for  a  user  to  work 
with  the  database.  An  editing  capability  was  developed  to 
permit  database  updating.  A  memory  management  system  was 
developed  for  manipulation  of  maps  too  large  to  fit  into 
main  memory.  Finally,  the  original  database  of  regions  was 
augmented  with  a  set  of  point  and  linear  feature  data  from 
the  same  geographical  region.  Those  data  were  also  quadtree 
encoded,  and  programs  were  written  to  answer  queries 
( points-in-region ,  lines-meetlng-reglon)  that  make  use  of 
more  than  one  type  of  data. 

6.2.  Plana 

It  is  planned  to  extend  the  work  on  this  project  to 
evaluate  other  types  of  hierarchical  representations  for  re¬ 
gions,  linear  features,  and  point  data.  These  representa¬ 
tions  include 

(a)  For  point  data:  point  quadtrees,  K-d  trees,  GRID 

files,  EXCELL 

(b)  For  linear  feature  data:  Strip  trees,  edge  quad¬ 

trees,  line  quadtrees 

(c)  For  region  data:  B-tree  encoded  quadtrees,  pyram¬ 

ids,  DF-expresslons ,  quadtree  Medial  Axis 

Transforms,  forest-based  methods. 

The  evaluation  will  make  use  of  the  same  data  base  used  on 
the  present  project.  It  will  involve  timing  and  storage 
space  studies,  and  will  also  Investigate  the  structure's 
amenability  to  use  in  an  off-line  storage  environment. 

Other  extensions  include  enhancement  of  the  query 
language,  and  an  Investigation  of  representations  for  gray¬ 
scale  data  (in  contrast  with  binary  Images).  All  methods 
will  be  scrutinized  from  the  viewpoint  of  their  amenability 
to  use  in  an  off-line  environment.  The  evaluation  will  make 
use  of  the  same  database  used  in  Phases  I  and  II  and  will 
consist  of  studies  of  time  and  storage  requirements. 


Facilities  used 


The  computer  used  during  this  project  was  a  VAX  11/780 
produced  by  the  Digital  Equipment  Corporation.  It  has  four 
megabytes  of  actual  memory,  six  megabytes  of  virtual  memory, 
a  disk  fetch  speed  of  approximately  0.6  megabits  per  second, 
and  a  memory  cycle  speed  of  approximately  1400  nanoseconds. 
The  wordsize  for  the  VAX  is  32  bits  broken  into  four  8-bit 
bytes.  Data  is  stored  on  two  DD  11/300  disk  drives  produced 
by  Plessey  Peripheral  Systems.  Each  disk  drive  has  a 
storage  capacity  of  300  megabytes.  The  VAX  11/780  runs 
under  the  UNIX  operating  system  (Berkley  Release  4.1). 


The  picture  output  device  used  by  this  project  is  a 
Grinnell  GMR-27  Display  Processor.  Its  memory  consists  of 
thirteen  512x512  bitplanes.  Twelve  of  these  bitplanes  carry 
color  information  (four  bits  for  each  of  the  colors:  blue, 
green,  and  red).  The  thirteenth  bitplane  is  used  for  a 
white  overlay  capability.  The  high  order  eight  bitplanes  of 
the  twelve  color  bitplanes  can  also  be  displayed  to  create  a 
grayscale  output.  The  output  speed  of  quadtrees  on  this 
device  compares  favorably  to  a  raster  scan  output  of  a  pic¬ 
ture  file,  because  the  GMR-27  can  output  a  rectangle  on  the 
display  screen  directly  from  the  rectangle's  coordinates 
(i.e.,  a  separate  command  is  not  necessary  for  each  pixel  in 
the  .’ectangle  as  is  done  when  a  picture  file  is  output  in 
raster  scan  mode). 
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